I've seen this posted elsewhere but the proposed solutions don't apply to, or are simply 'solutions' we can't apply in this environment. We occasionaly see one or both of the following on desktops and laptops alike "Could not reconnect all network drives" balloon message and an icon in the system tray No balloon message but the icon exists in the system tray Understandably this happens off the network (although we want to suppress that), however, this happens while on the network. In every case that we've seen this, when we check 'Computer' (formerly 'My Computer'), all of the network drives are connected. Windows reports a 'false positive' - so to speak. Briefly here's our setup Win 7 Enterprise in a domain environemnt Built-in Win 7 firewall has been disabled; No third-party software firewall solutions present Network drives are mapped via net use /persistent:yes, Explorer with reconnect & logon set & via exporting/importing the network drive information from HKCU\Network We use a login script, however, the login script does not handle the mapping of all of our network drives. This is because we have a number of different departments, who, over the years, used overlapping drive letters and there are some situations where users also overlap departments that use overlapping drive letters. (This goes back before my time.) So instead, users map their own drives, remember the credentials and reconnect at logon. Furthermore, when users call the Help Desk, the Help Desk uses the '/persistent:yes' switch/parameter when doing mappinv via command line. Not sure if this is relevant, but, when we move users to a new machine, or reimage their machine, we backup & restore the HKCU\Network key, which houses the mapped connections, to make the transition nearly seamless. (So, doing a `net use * /delete /Y` to 'fix' this problem is not an option here.) Is there anything I can do to to prevent that message from popping up along with preventing the icon from displaying in the system tray? Although the "Always wait for the network at computer startup and logon" and "Turn off all balloon notifications" GPO settings are set to 'Enabled', those are the only potentially relevant GPO setting I could find, and they don't appear to fix this issue. Also, I've been looking at the setting discussed here http://support.microsoft.com/kb/937624/en-us but although users are promoted to local administrators via a GPO I'm not certain that applies here or if that will help. Lastly, thanks to another post I found on the forums, I ran across this setting http://support.microsoft.com/kb/297684 and am wondering if this is worth investigating, however, I'm concerned of how changing this setting may affect the servers the user's are connecting to based on way this sentence was phrased: "This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. " If we set this value to some insanely high value (65535), how might that impact a server with a 1000 connections? Any suggestions are greatly appreciated.

Two things First: Bump! Second: While were on the subject of network drives, I wanted to share with everyone something else we've discovered. In Windows XP, if a user has a persistent network connection (a remembered network drive), when they logon, it immediately reconnects the drive. If the same user logs into the same Windows XP machine while offline (disconnected from the network) naturally the drives don't reconnect. They're in the same 'disconnected' state as in we've observed. If we take that same user and have them connect to our VPN system, within seconds of establishing a connection, Explorer re-connects the network drives without the user doing anything. This is nearly instant, not a 30-60 second thing, as once I connected to the VPN I opened Explorer and the drives were already connected. So, I don't expect there to be any real surprises at this point, but here's the interesting part... Windows 7 behaves differently. If you follow the same steps in Windows 7, Explorer will *not* re-connect the network drives; It doesn't automatically re-establish a connection to the network like Windows XP. We've tested this on a few Windows XP & Windows 7 machines and its 100% repeatable. Something specific must be triggered before Explorer [on Windows 7] re-connects the network drives. I won't go into great detail but I will say that UNC paths (\\server\share\file) work fine (be it a shortcut or start > run), while anything that references a drive letter (F:\file, G:\Folder) fails. (I'm curious, as anyone else noticed this?) The good news is that we opened a ticket with Microsoft and they were able to reproduce this problem and have confirmed it is a 'bug' but there's no word on whether or not this is seen as something that needs to be fixed. I mentioned the network drive bubble & icon issue but they were more focused on the network drive issue I discuss here. If you want more information on this, let me know if you want to know. I have a video that details this but I can't release it just yet without first cleaning it up.

Bump....?

I think I've found a workaround for this issue. If you disconnect the mapped drives from My Computer, log off and back on again (I have persistence enabled) it makes the reconnect error balloon stop popping up.

Thanks for taking the time to read & reply to this thread. How do you disconnect the mapped drives: Right click disconnect? net use Drive: /delete /y? Some other method? As time permits I'll try to test this but I'm concerned abhout implementing this workaround programmatically across ~1500 machines. Here is another post discussing the same thing: http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/48f5ca04-6561-404d-b3ab-897320593aa6

Hi JuliusPIV.... I am curious if you have found out any further info on the re-connection of network drive's when connecting to the VPN. This has been a on-going issue for the company I work for....for the last few months. But now, we just rolled out 130 new windows 7 machines to be used primarily off-site. They have a batch file they run, that pulls info from a network drive. So naturally, the sales people are not going in and initiating the network drive first. And as you said, Windows XP did this on its own. Have you heard anything back from Microsoft for a fix to this bug? Or have you perhaps found a work around to the issue? I was going to begin working on a script to put in the VPN client that would connect this drive for them....but have not found the time. And if Microsoft has a hotfix or something in the works, that would be great to know. Any further info you could provide would be great. Thanks!!

It actually worked for right-click disconnect and net use Drive: /delete /y. It did randomly resurface once, but the reason for that was that Active Directory was mapping the user drive automatically at login, but the drive was being mapped in the login script as well. I removed it from the login script, and haven't seen it since. I started off implementing this on a few computers for testing purposes, and as of Monday have successfully rolled this out to the entire company (about 150 users). I have not had any user complaints, or seen the issue since.

Good point - as part of our migration process we backup existing mapped drives which also includes their home directory. We'll try to take that into consideration thanks for sharing this is great news.

Found this in another forum Whenever I mapped the drives in Windows it asked for credentials. However these credentials were then created with a persistence type of "Logon session" which is not editable. Having discovered this, I restarted windows and then before supplying the credentials to reconnect the mapped drives, I added credentials explicitly as follows: 1. Goto Control Panel -> All control Panel Items -> Credentials Manager 2. Next to the heading "Windows Credentials" click on the link "Add a Windows credential". 3. Enter the name of your server and the appropriate credentials. The result is an entry that has a persistence type of "Enterprise". This seems to do the trick. (I then restarted windows) This fixed the problem for me, hope it does for you. BTW. In order for windows to resolve the server name you may have to create an entry in the "Hosts" file located in "C:\Windows\System32\drivers\etc".